Більше ніж 50,000 людей записались на курс Odersky  “Functional Programming Principles in Scala” на Coursera. Це гігантське число розробників, для яких це могло бути першим контактом зі Scala, функціональним програмуванням, або обома одночасно.

Якщо ви читаєте це, можливо, ви один з них, або ви почали вивчати Scala з інших причин. В жодному разі, якщо ви почали вивчати Scala, ви бажаєте поглинути глибше в цю прекрасну мову, але вона все ще видається трохи екзотичною або туманною для вас. Тоді ці статті, що я розпочинаю, саме для вас. 

Навіть коли курс Coursera торкається загалу, який ви маєте знати про Scala, існуючі обмеження часу роблять неможливим пояснити все в деталях. Як результат, деякі можливості Scala можуть ввижатись вам як магія, якщо ви нові в цій мові. Ви можете використовувати їх деяким чином, але ви не повністю схопили як вони роблять, та, більш важливо, чому вони роблять таким чином.

В цій частині, та в наступних тижні, я хочу прояснити речі та видалити знаки запитання. Я буду також пояснювати деякі з можливостей мови Scala та бібліотеки, з якими я мав проблеми, коли я починав навчатись мові. Частково тому, що я не знайшов гарних пояснень до них, але замість цього натрапив на них в дикій природі. Коли це стосується, я також надаватиму інструкції, як використовувати ці можливості ідіоматичним™ шляхом.

Досить вступів. Перед тім, як я почну, майте на увазі, що хоча проходження слухачем курсу Coursera не є попередньою вимогою для слідування цій серії, мати знання Scala, що може бути отримано з лекцій, безумовно, буде корисне. Та я буду часом посилатись на курс.

То як насправді робить ця штуковина з порівнянням шаблонів?

В курсі Coursera ви натрапите на дуже потужну можливість мови Scala: порівняння з шаблоном. Це дозволяє вам декомпонувати дані структури даних, прикріпляючи значення, з яких вони побудовані, до змінних. Однак це не уникальна до Scala ідея. Інші помітні мови, в яких порівняння з шаблоном відіграють важливу грають  роль, це Haskell та Erlang, як для прикладу.

Якщо ви слідували відео лекціям, ви бачили, що ви можете декомпонувати різні типи структур даних з використанням порівнянням шаблонів, серед яких списки, потоки, та любі примірники кейс класів. Чи є цей перелік структур даних, що можна деструктурувати, є фіксованим, чи ви можете розширити його якимось чином? Але спершу, як це в дійсності це дійсно робить? Чи є деяка магія, що дозволяє вам писати речі як нижче?

1
2
3
4
5

case class User(firstName: String, lastName: String, score: Int)
def advance(xs: List[User]) = xs match {
  case User(_, _, score1) :: User(_, _, score2) :: _ => score1 - score2
  case _ => 0
}

Як це з'ясовується, нічого такого немає. Або не багато. Причина, чому ви в змозі писати код вище (не важливо, як багато сенсу має цей окремий приклад), це існування так званих екстракторів.

В найбільш широко застосованій формі, екстрактор має зворотню до конструктора роль: коли останній створює об'єкти з наданого списку параметрів, екстрактор виділяє параметри, з яких був стіорений об'єкт при створенні.

Бібліотека Scala має декілька попередньо визначені екстракторів, та ви скоро побачите один з них. Кейс класи є особливими, бо Scala автоматично створює компанйон об'єкт для них: об'єкт-синглтон, що містить не тільки метод apply для створення нових примірників кейс класу, але також метод unapply  – метод, що потрібно реалізувати об'єкту, щоб він мав екстрактор. 

Наш перший екстрактор, йо!

Є  більше однієї можливої сигнатури для валідного метода unapply, але ми почнемо з тих, що, найбільш вірогідно, будуть використовуватись. Давайте уявимо, що наш клас User не є кейс класом взагалі, але замість цього є трейтом, з двома класами, що розширюють його, та на момент, він містить тільки одне поле:

1
2
3
4
5

trait User {
  def name: String
}
class FreeUser(val name: String) extends User
class PremiumUser(val name: String) extends User

Ми бажаємо реалізовати екстрактори для класів FreeUser та PremiumUserв відповідних об'єктах-компанйонах, саме так, як би зробила Scala в ціх кейс класах. Якщо ваш екстрактор призначений тільки для виділення одного параметру з наданого об'єкту, сигнатура метода unapplyвиглядає так:

1

def unapply(object: S): Option[T]

Метод очікує деякий об'єкт типу S, та повертає Option типу T, що є типом параметра, який він екстрагує. Пам'ятайте, що Optionє безпечною альтернативою Scala до існування значень null. Про це буде окрема стаття, але наразі досить знати, що метод unapplyповертає або Some[T] (якщо він може успішно виділити параметр з даного об'єкта) або None, що означає, що параметри не можуть бути виділені за правилами, визначеними в реалізації екстрактора.

Ось наші екстрактори:

1
2
3
4
5
6
7
8
9
10
11
12

trait User {
  def name: String
}
class FreeUser(val name: String) extends User
class PremiumUser(val name: String) extends User

object FreeUser {
  def unapply(user: FreeUser): Option[String] = Some(user.name)
}
object PremiumUser {
  def unapply(user: PremiumUser): Option[String] = Some(user.name)
}

Ми можемо тепер використовувати їх в REPL:

1
2

scala> FreeUser.unapply(new FreeUser("Daniel"))
res0: Option[String] = Some(Daniel)

Але ви звичайно не будете викликати їх напряму. Scala викликає метод екстрактора   unapply, якщо екстрактор використовується як шаблон екстрактора.

Якщо результат виклику  unapply є Some[T], це означає, що шаблон співпадає, та виділене значення прив'язується до змінної, задекларованої в шаблоні. Якщо це None, це означає, що шаблон не співпав, та буде перевірятись наступна умова співпадіння.

Давайте використаємо наші екстрактори для порівняння з шаблоном:

1
2
3
4
5

val user: User = new PremiumUser("Daniel")
user match {
  case FreeUser(name) => "Hello " + name
  case PremiumUser(name) => "Welcome back, dear " + name
}

Як ви вже помітили, обоє наші екстрактори ніколи не повертають None. Приклад показує, що це має більше сенсу, ніж може вважатись спочатку. Якщо ви маєте об'єкт, що може бути одного типу, або іншого, ви можете перевірити його тип, та розкласти його в той же час.

В прикладі шаблон FreeUser не буде співпадати, оскільки він очікує об'єкт іншого типу, що ми можемо передати йому. Оскільки він бажає об'єкт типу FreeUser, не типу  PremiumUser, цей екстрактор навіть ніколи не викликається. Однак значення user тепер передається до метода unapplyметода компанйон-об'єкта PremiumUser, тому що цей екстрактор використовується в другому шаблоні. Цей шаблон співпасть, а повернуте значення буде прикріплене до параметру name.

Пізніше в цій статті ми побачимо приклад екстрактора, що не завжди повертає Some[T].

Виділення декількох значень

Тепер уявімо, що наші класи такі, що ми бажаємо виділяти з них більше число полів:

1
2
3
4
5
6
7

trait User {
  def name: String
  def score: Int
}
class FreeUser(val name: String, val score: Int, val upgradeProbability: Double)
  extends User
class PremiumUser(val name: String, val score: Int) extends User

Якщо шаблон екстрактора призначений для декомпозиції даної структури даних, де більше одного параметра, сигнатура метода екстрактора unapplyвиглядає так:

1

def unapply(object: S): Option[(T1, ..., Tn)]

Метод очікує деякий об'єкт типу  S, та повертає Option типу TupleN, де N є кількістю параметів до виділення.

Давайте адаптуємо наші екстрактори до модифікованих класів:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

trait User {
  def name: String
  def score: Int
}
class FreeUser(val name: String, val score: Int, val upgradeProbability: Double)
  extends User
class PremiumUser(val name: String, val score: Int) extends User

object FreeUser {
  def unapply(user: FreeUser): Option[(String, Int, Double)] =
    Some((user.name, user.score, user.upgradeProbability))
}
object PremiumUser {
  def unapply(user: PremiumUser): Option[(String, Int)] = Some((user.name, user.score))
}

Тепер ми можемо використовувати цей екстрактор для співпадіння шаблонів, точно як ми робили в попередній версії:

1
2
3
4
5
6

val user: User = new FreeUser("Daniel", 3000, 0.7d)
user match {
  case FreeUser(name, _, p) =>
    if (p > 0.75) name + ", what can we do for you today?" else "Hello " + name
  case PremiumUser(name, _) => "Welcome back, dear " + name
}

Логічний екстарктор

Іноді вам насправді не треба виділити параметри зі структури даних, з якою ви робите співпадіння – замість цього ви просто бажаєте виконати деяку логічну перевірку. В цьому випадку стане в нагоді третя, та остання з існуючих сигнатур метода unapply, що очікує значення значення типу S та повертає  Boolean:

1

def unapply(object: S): Boolean

Використаний в шаблоні, він дасть співпадіння, якщо екстрактор поверне true. Інакше буде спробоване наступне порівняння.

В попередньому прикладі ми мали деяку логіку, що перевіряла, чи простий користувач може бути підозрюваним в якості скорого кандидата на апгрейд. Давайте покладемо цю логіку в наш власний логічний екстрактор:

1
2
3

object premiumCandidate {
  def unapply(user: FreeUser): Boolean = user.upgradeProbability > 0.75
}

Як ви можете бачити, не є необхідним для екстрактора знаходитись в об'єкті-компанйоні класа, до якого він стосується. Використання цього логічного екстрактора є простим:

1
2
3
4
5

val user: User = new FreeUser("Daniel", 2500, 0.8d)
user match {
  case freeUser @ premiumCandidate() => initiateSpamProgram(freeUser)
  case _ => sendRegularNewsletter(user)
}

Цей приклад показує, що логічний екстратор використовується простою передачей йому пустого списку параметрів, що має сенс, бо насправді нема ніякого виділення жодних параметрів для прикріплення до змінних.

Є одна інша особливість цього приклада: я претендую на те, що наша функціональна функція initiateSpamProgram очікує екземпляр FreeUser, оскільки преміум користувачі ніколи не отримуватимуть спам. Однак, наше співпадіння виконується з шаблоном проти любого типу User, так що я не можу передавати user до функції initiateSpamProgram – не без огидного кастингу типів.

На щастя, порівняння шаблонів Scala дозволяє прикріпляти до змінної значення, що співпадають, також з використанням типу, що очікує використаний екстрактор. Це робиться за допомогою оператора @. Оскільки наш екстрактор premiumCandidate очікує примірник FreeUser, ми маємо, таким чином, прикріплення співпавшого значення до змінної freeUser типу FreeUser.

Персонально я не дуже багато використовував логічні екстрактори, але добре знати, що вони існують, бо раніше або пізніше ви опинитесь в ситуації, коли вони знадобляться. 

Шаблони інфіксних операторів

Якщо ви слідували за Scala курсом на Coursera, ви знаєте, що ви можете деструктувати списки та потоки в спосіб, що є спорідненим до того, як ви створюєте їх, використовуючи оператор cons , :: або #::відповідно:

1
2
3
4
5

val xs = 58 #:: 43 #:: 93 #:: Stream.empty
xs match {
  case first #:: second #:: _ => first - second
  case _ => -1
}

Можливо ви дивуєтесь, як це можливо. Відповідь полягає в тому, що в якості альтернативи до нотації шаблонів екстракторів, що ми вже бачили, Scala також дозволяє екстракторам бути задіяними в інфіксній нотації. Таким чином, замість написання e(p1, p2), де e є екстрактор, та p1 та p2 є параметри, що будуть виділені з наданої структури даних, завжди можливо записати p1 e p2.

Таким чином шаблон інфіксної операції head #:: tail може також бути записаний як #::(head, tail), та наш екстрактор PremiumUser також може бут використаний в шаблоні, що читаєься name PremiumUser score. Однак, це не щось, що вам треба робити на практиці. Використання шаблону інфіксного оператора рекомендований тільки для екстракторів, що дійсно призначені для читання як оператори, що вірне для операторів  cons List та Stream, але безсумнівно не для нашого екстрактора PremiumUser.

Ближчий погляд на екстрактор Stream

Навіть зважаючи, що немає нічого особливого в тому, як екстрактор #:: може бути задіяний в порівнянні шаблонів, давайте поглянемо на нього, щоб краще зрозуміти, що відбувається в нашому коді порівняння. Також це гарний приклад екстрактора, що, в залежності від стану переданої структури даних, може повертати None, і, таким чином, не співпадати.

Ось повний екстрактор, взятий з джерел Scala 2.9.2:

1
2
3
4
5

object #:: {
  def unapply[A](xs: Stream[A]): Option[(A, Stream[A])] =
    if (xs.isEmpty) None
    else Some((xs.head, xs.tail))
}

Якщо даний примірник Stream пустий, він повертає None. Таким чином, case head #:: tail не співпадає для пустого потоку. Інакше повертається Tuple2, перший елемент якого є головою потоку, тоді як другий елемент кортежу є хвіст, що знову є Stream. Таким чином, case head #:: tail буде співпадати для потока з одного, або більше, елементів. Якщо він має тільки один елемент, tail буде прикріплений до пустого потока. 

Щоб зрозуміти, як цей екстрактор робить для нашого приклада співпадіння, давайте перепишемо цей приклад, йдучи від шаблону інфіксного операнду до звичайної нотації:

1
2
3
4
5

val xs = 58 #:: 43 #:: 93 #:: Stream.empty
xs match {
  case #::(first, #::(second, _)) => first - second
  case _ => -1
}

Спершу екстрактор викликається для початкового потокуxs, що переданий в блок порівняння. Екстрактор повертає Some((xs.head, xs.tail)), так що first прив'язане до  58, тоді як хвіст xs знову передається в екстрактор, що використовується знову в першому порівнянні. Знову, він повертає голову та хвіст, як Tuple2, огорнуте в Some, так що second прив'язане до значення 43, тодя як хвіст прив'язується до підстановочного символа _, і, таким чином, відкидається.

Використання екстракторів

Так що, коли і як ви, насправді, повинні використовувати власні ексрактори, особливо беручи до уваги, що ви можете отримати деякі корисні екстрактори задурно, якщо використовуєте кейс класи?

Хоча деякі люди вказують, що використання кейс класів, та застосування до них співпадіння шаблонів з ними ламає інкапсуляцію, пов'язуючи спосіб, що ви порівнюєте дані, з конкретним представленням, цей критицизим зазвичай походить від об'єктно-орієнтованого погляду на речі. Це гарна ідея, якщо ви бажаєте робити функціональне програмування в Scala, використовувати кейс класи як алгебраїчні типи даних (ADT), що містять тільки дані, але жодної поведінки.

Зазвичай, використання ваших власних екстракторів необхідне тільки в випадку, якщо ви бажаєте виділяти з типу те, над чим ви не маєте влади, або якщо вам потрібні додаткові шляхи співпадіння з шаблоном проти певних даних. Наприклад, загальним використанням екстракторів є виділення осмислених значень з деякого рядка. В якості вправи подумайте, як ви повинні реалізовати та використовувати URLExtractor, що приймає Stringпредставлення URL.

Висновок

В цій першій частині з серії ми розглянули екстрактори, робочу конячку за співпадінням шаблонів Scala. Ви навчились, як реалізувати ваші власні екстрактори, та як реалізація екстрактора пов'язана з його використанням в шаблоні.

Ми не розглянули все, що можна сказати про екстрактори, тому що ця стаття вже є досить довгою. В наступній частині з цієї серії я збираюсь повернутись до екстракторів, розповідаючи, як реалізувати їх, якщо ви бажаєте число змінних екстрагованих параметрів в шаблоні.

Дайте мені знати, чи ця стаття була корисною для вас, або дещо не було вам зрозуміло.

В першій частині цієї серії ми вивчили, як втілити наші власні екстрактори, та як ці екстрактори можуть використовуватись для порівняння шаблонів. Однак ми дискутували тільки екстрактори, що дозволяють вам деструктурувати даний об'єкт в фіксоване число параметрів. Але для деяких різновидів структур даних Scala дозволяє вам виконати порівняння шаблонів, очікуючи довільне число виділених параметрів.

Наприклад, ви можете використовувати шаблон, що співпадає тільки зі списком, що містить рівно два елементи, або зі списком з рівно трьох елементів:

1
2
3
4
5
6

val xs = 3 :: 6 :: 12 :: Nil
xs match {
  case List(a, b) => a * b
  case List(a, b, c) => a + b + c
  case _ => 0
}

Ще більше, якщо ви бажаєте порівняти списки з довжиною, про яку ви не турбуєтесь, ви можете викоритовувати підкреслення _*:

1
2
3
4
5

val xs = 3 :: 6 :: 12 :: 24 :: Nil
xs match {
  case List(a, b, _*) => a * b
  case _ => 0
}

Тут перший шаблон співпадає, прикріплюючі перші два елементи до змінних a та b, та повністю ігноруючи решту списку, безвідносно до того, як багато лишилось тих елеметнів. 

Зрозуміло, екстрактори для ціх типів шаблонів не можуть бути реалізовані у спосіб, що я виклав в першій статті. Нам потрібен шлях вказати, що екстрактор приймає об'єкт певного типу, та деструктує його в послідовність виділених значень, де довжина цієї послідовності невідома під час компіляції.

ВведемоunapplySeq, метод екстарктора, що дозволяє робити семе це. Давайте поглянемо на одну з можливих сігнатур метода:

1

def unapplySeq(object: S): Option[Seq[T]]

Він очікує об'єкт типу S, та повертає або None, якщо об'єкт зовсім не співпадає, або послідовність виділеного типу T, огорнутого в Some.

Приклад: виділення наданих імен

Давайте використаємо цей тип методів екстрактора в наступному вигаданому прикладі. Скажімо, в деякій частині застосування ми отримуємо ім'я користувача як String. Цей рядок може містити друге, або третє ім'я користувача, якщо він має більше одного наданого імені. Таким чином, можливі значення можуть бути "Daniel", або"Catherina Johanna", або "Matthew John Michael". Ми бажаємо мати змогу порівняти ці імена, виділяючи та прив'язуючи окремі надані імена.

Ось дуже проста реалізація екстрактора в термінах метода unapplySeq, що дозволить нам зробити це:

1
2
3
4
5
6

object GivenNames {
  def unapplySeq(name: String): Option[Seq[String]] = {
    val names = name.trim.split(" ")
    if (names.forall(_.isEmpty)) None else Some(names)
  }
}

Беручи String, що містить одне або більше імен, це буде виділяти їх як послідовність. Якщо вхідне ім'я не містить щонайменьше одного наданого імені, цей екстрактор буде повертати None, і, таким чином, шаблон в цьому використаному екстракторі не буде співпадати з рядком.

Тепер ви можете надати наш новий екстрактор до тесту:

1
2
3
4

def greetWithFirstName(name: String) = name match {
  case GivenNames(firstName, _*) => "Good morning, " + firstName + "!"
  case _ => "Welcome! Please make sure to fill in your name!"
}

Цей вправний малий метод повертає привітання для наданого імені, ігноруючи все, крім першого імені. greetWithFirstName("Daniel") буде повертати "Good morning, Daniel!", а greetWithFirstName("Catherina Johanna") поверне "Good morning, Catherina!"

Комбінація екстракції фіксованих та змінних параметрів

Іноді ви маєде деякі значення, що мають бути виділені, що ви знаєте під час компіляції, плюс додаткові опціональні послідовності значень.

Давайте уявімо в нашому прикладі, що вхідне ім'я містить повне ім'я, не тільки надане. Можливі значення можуть бути "John Doe" або"Catherina Johanna Peterson". Ми бажаємо порівнювати такі рядки з використанням шаблонів, що завжди прикріплює останнє ім'я людини до першої змінної в шаблоні, та перше ім'я до другої змінної, за якими слідує довільне число додаткових наданих імен.

Це може бути досягнено за допомогою невеликої модифікцїі методаunapplySeq, з використанням іншої сигнатури метода:

1

def unapplySeq(object: S): Option[(T1, .., Tn-1, Seq[T])]

Як ви можете бачити, unapplySeq також може повертати Option з TupleN, де останній елемент кортежу має бути послідовністю, що містить змінну частину виділених значень. Ця сигнатура методу повинна бути дещо знайомою, тому що вона подібна до однієї з можливих сигнатур методу unapply, що я показував на минулому тижні. 

Ось екстрактор, що використовує це:

1
2
3
4
5
6
7

object Names {
  def unapplySeq(name: String): Option[(String, String, Seq[String])] = {
    val names = name.trim.split(" ")
    if (names.size < 2) None
    else Some((names.last, names.head, names.drop(1).dropRight(1)))
  }
}

Подивіться ближче на повертаємий тип, та на конструкцію Some. Наш метод повертає Option з Tuple3. Цей кортеж стоврений за допомогою синтаксиса Scala дял літералів, просто покладаючи три елементи – останнє ім'я, перше ім'я та послідовність додаткових наданих імен – в парі дужок.

Якщо цей екстрактор використовується в шаблоні, шаблон буде співпадати, якщо щонайменьше останнє ім'я міститься в наданому вхідному рядку. Послідовність додаткових наданих імен створюється, відкидаючи перший та останній елемент з послідовності імен.

Ми можемо використовувати цей екстрактор для реалізації альтернативного метода привітання:

1
2
3
4

def greet(fullName: String) = fullName match {
  case Names(lastName, firstName, _*) => "Good morning, " + firstName + " " + lastName + "!"
  case _ => "Welcome! Please make sure to fill in your name!"
}

Почувайтесь вільним погратись з цім в REPL або на робочому листі.

Підсумок

В цій главі ми навчились, як реалізовати та використовувати екстрактори, що повертають послідовності виділених значень змінної довжини. Екстрактори є досить потужним механізмом. Вони часто можуть  бути повторно використані в гнучкий спосіб, та провадити потужний шлях для розширення типів шаблонів, з якими ви можете робити порівняння.

Ми будемо переглядати екстрактори в навчальному прикладі наприкінці кінця цієї серії. В наступній частині, однак, я надам огляд різних шляхів, яким шаблони можуть застосовуватись в коді Scala – є більше варіантів порівнянь з шаблоном, ніж ви вже бачили до тепер. 

Оновлення, 24.01.2013: Я оновив приклад кода, реалізуючи екстрактор  GivenNames. Дякую Christophe Bliard, що вказав на помилку.

В перших частинах цієї серії я витратив деякий час, пояснюючи, що насправді відбувається, коли ви деструктуєте примірник кейс класу в шаблоні, та як писати ваші власні екстракторі, дозволяючи вам деструктувати любі типи об'єктів, в любий бажаний спосіб.

Тепер настав час зробити огляд, де шаблони можуть насправді використовуватись в вашому Scala коді, оскільки до тепер ви бачили тільки одну з різноманітних шляхів для використання шаблонів. От де ми є!

Вирази порівняння шаблонів

Одне місце, де можуть з'являтись шаблони, це вирази поірвняння шаблонів. В такій спосіб використання шаблонів має бути дуже вам знайомим після проходження курсу Scala на Coursera, та впродовж цієї серії. Ви маєте неякий виразe, за який слідує ключове слово matchта блок, що може містити любе число випадків. Випадок, в свою чергу, складається з ключового слова case, за яким слідує шаблон, та, опціонально, зліва частина охоронця, плюс блок зправа, що буде виконано, якщо шаблон співпадає.

Ось простий приклад, що використовує шаблон, та охоронця в одному з випадків:

1
2
3
4
5
6

case class Player(name: String, score: Int)

def printMessage(player: Player) = player match {
  case Player(_, score) if score > 100000 => println("Get a job, dude!")
  case Player(name, _) => println("Hey " + name + ", nice to see you again!")
}

Метод printMessage має тип Unit, його єдине призначення полягає в побічному ефекті, наразі в друку повідомлення. Важливо пам'ятати, що ви не маєте використовувати порівняння з шаблоном, як ви це робили з використанням твердження switch в мовах, як Java. Те, що ми тут використовуємо, називається виразом порівняння з шаблоном не даремно. Їх повернуте значення є те, що повертається з блоку, який відповідає до першого співпавшого шаблону.

Звичайно, є гарною ідеєю отримати зиск з цього, оскільки це дозволяє вам розділити дві речі, що насправді не належать одне до одного, роблячи простішим тестування вашого коду, також. Ми також отримали приклад вище, наступним чином:

1
2
3
4
5

def message(player: Player) = player match {
  case Player(_, score) if score > 100000 => "Get a job, dude!"
  case Player(name, _) => "Hey " + name + ", nice to see you again!"
}
def printMessage(player: Player) = println(message(player))

Тепер, ми маємо виділити метод message, що повертає типString. Це, загалом, чиста функція, що повертає вираз порівняння шаблону. Ви можете також зберігти результат такого порівняння, як значення, або, звичайно, присвоїти його змінній.

Шаблони в визначеннях значення

Інше місце, де в Scala може трапитись порівняння з шаблоном, є ліва частина визначення значення (та в визначенні змінної, в цьому значенні, але ми бажаємо написати наш Scala код в функціональному стилі, так що ми не бажаємо бачити багато визначень змінних в цій серії). Давайте вважати, що ми маємо метод, що повертає поточного гравця. Ми будемо використовувати умовну реалізацію, що постійно повертає одного гравця:

1

def currentPlayer(): Player = Player("Daniel", 3500)

Ваше звичайне визначення виглядатиме так:

1
2

val player = currentPlayer()
doSomethingWithTheName(player.name)

Якщо ви знаєте Python, ви, можливо, знайомі з можливістю, відомою як розпакування послідовності. Факт, що ви можете використовувати любі шаблони зліва від визначення значення, або визначення змінної, дозволяє вам писати ваш Scala код в подібному стилі. Ми можемо змінити код вище, та деструктувати наданого поточного гравця , при тому присвоювуючи його до лівої сторони:

1
2

val Player(name, _) = currentPlayer()
doSomethingWithTheName(name)

Ви можете робити це з кожним шаблоном, але, загалом, є гарною ідеєю, щоб переконатись, що ваш шаблон завжди співпадає. Інакше ви станете свідком виключення під час виконання. Наприклад, наступний код
 проблематичним. Методscores повертає список досягнень. В нашому коді нижче, це метод просто повертає пустий список, щоб проілюструвати цю проблему.

1
2
3

def scores: List[Int] = List()
val best :: rest = scores
println("The score of our champion is " + best)

Отакої, ми отримали MatchError. Здається, що наша гра не є успішною, кінець кінцем, не маючи будь-яких рейтингів.

Безпечний, та дуже зручний, спосіб використання шаблонів в цей спосіб є деконструкцію кейс класів, чий тип відомий під час компіляції. Також, коли робимо з кортежами, це робить ваш код значно більш читабельним. Давайте уявімо, що ми маємо функцію, що повертає ім'я гравця, та його бали, в вигляді кортежа, не використовуючи клас Player, що ми використовували до цього:

1

def gameResult(): (String, Int) = ("Daniel", 3500)

Доступ до полів кортежа завжди виглядає дуже незручним:

1
2

val result = gameResult()
println(result._1 + ": " + result._2)

Є безпечним деструктурувати наш кортеж в визначенні типу, коли ми знаємо, що маємо справу з Tuple2:

1
2

val (name, score) = gameResult()
println(name + ": " + score)

Це читається значно краще, чи не так?

Шаблони в for осягненнях

Шаблони також мають дуже впливове місце в for осягненнях. Для початку, for осягнення може також містити визначення значень. Та все, що ви вивчили щодо використання шаблонів в лівій стороні визначень значень, остається вірним для визначень значень в осягненнях. Таким чином, якщо ми маємо колекцію результатів гравців, та бажаємо скласти їх рейтинг, що в нашій грі є тільки набором імен гравців, що перетнули деякий рубіж по очках, ми можемо зробити це в дуже зрозумілий спосіб завдяки осяжності:

1
2
3
4
5
6
7
8

def gameResults(): Seq[(String, Int)] =
  ("Daniel", 3500) :: ("Melissa", 13000) :: ("John", 7000) :: Nil

def hallOfFame = for {
  result <- gameResults()
  (name, score) = result
  if (score > 5000)
} yield name

Результатом є List("Melissa", "John"), оскільки перший гравець на задовільняє умові охоронця.

Це може бути записане навіть більш стисло, оскільки в for осяжності ліва сторона генератора також є шаблоном. Так що, замість спочатку присвоювати кожний результат гри до result, ми можемо напряму деструктувати результат в лівій стороні генератора:

1
2
3
4

def hallOfFame = for {
  (name, score) <- gameResults()
  if (score > 5000)
} yield name

В цьому прикладі шаблон (name, score) завжди співпадає, так що, якщо б не було твердження охоронця, if (score > 5000), for осяжність була б еквівалентною до простого відображення з кортежів на імена гравців, без жодної фільтрації.

Важливо знати, що шаблони в лівій стороні генератора можуть все ще бути використані для цілей фільтрації – якщо шаблон в лівій частині не співпадає, відповідний елемент буде відсіяно.

Щоб продемонструвати це, давайте уявімо, що ми маємо послідовність списків, та ми бажаємо повернути розміри для непорожніх списків. Це означає, що ми маємо відфільтрувати всі непорожні списки, та потім повернути розміри тих, що залишились. Ось одне з рішень:

1
2
3
4
5

val lists = List(1, 2, 3) :: List.empty :: List(5, 3) :: Nil

for {
  list @ head :: _ <- lists
} yield list.size

Шаблон зліва генератора не співпадає з пустими списками. Це не викликає  MatchError, але призводить до виключення пустих списків. Таким чином, ми отримаємо List(3, 2).

Шабони та for осяжності є дуже природним та потужним поєднанням, та якщо ви проробите зі Scala деякий час, ви побачите, що ви використовуєти їх досить багато.

Анонімні функції

Нарешті, шаблони можуть використовуватись для визначення анонімних функцій. Якщо ви будь-коли використовували блок catch, щоб мати справу з виключеннями  Scala, тоді ви використовували цю можливість. Функції порівняння з шаблоном є привідом для окремого блог посту, оскільки є багато чого, що варто про них сказати. Таким чином, я уникну заглиблення в це використання шабонів, в цьому розділі, та замість цього залишаю вам обіцянку повернутись до цього в наступній частині цієї серії.

Оновлення: Виправдено помилку в очікуваному результаті hallOfFame for осяжності. Дякую Rajiv що вказав на це.

В попередній частині я надав огляд різних шляхів, як порівняння шаблонів може бути застосоване в Scala, завершуючи коротким спогадом про анонімні функції, як інше місце, де шаблони можуть знайти своє застосування. В цьому пості ми збираємось покалсти уважний погляд на можливості, що відкриває визначення анонімних функцій таким чином.

Якщо ви брали цчасть в курсі Scala на Coursera, або кодували на Scala деякий час, ви, вірогідно, писали анонімні функції на регулярній основі. Наприклад, беручи список наз пісень, що ви бажаєте перетворити на нижній реєстр для індексу пошуку, ви, можливо, визначали анонімну функцію, що ви передавали до методу map, таким чином:

1
2

val songTitles = List("The White Hare", "Childe the Hunter", "Take no Rogues")
songTitles.map(t => t.toLowerCase)

Або, якщо ви бажаєте ще коротше, ви можете нормалізувати функцію, таким чином, з використанням синтаксису заміщувача making use of Scala:

1

songTitles.map(_.toLowerCase)

Доки все гаразд. Однак давайте подивимось, як цей синтаксис виступає в дещо іншому прикладі: ми маємо послідовність пар, кожна представляє слово та його частоту в деякому тексті. Наша ціль відфільтрувати ці пари, чия частота нижче або виде деякого значення, та потім повернути залишок слів, без їх відповідних частот. нам треба написати функціюwordsWithoutOutliers(wordFrequencies: Seq[(String, Int)]): Seq[String].

Наше початкове рішення використовує методи filter та map, передаючи анонімні функції до них, з використанням знайомого синтаксису:

1
2
3
4
5

val wordFrequencies = ("habitual", 6) :: ("and", 56) :: ("consuetudinary", 2) ::
  ("additionally", 27) :: ("homely", 5) :: ("society", 13) :: Nil
def wordsWithoutOutliers(wordFrequencies: Seq[(String, Int)]): Seq[String] =
  wordFrequencies.filter(wf => wf._2 > 3 && wf._2 < 25).map(_._1)
wordsWithoutOutliers(wordFrequencies) // List("habitual", "homely", "society")

Це рішення має декілька проблем. Перша є тільки естетичною – доступ до полів кортежу є огидним, як на мене. Якщо ми бажаємо тільки деструктувати пару, ми можемо зробити цей код трохи більш приємним, та, можливо, більше читабельним.

На щастя,  Scala провадить альтернативний шлях написання анонімних функції: анонімна функція порівняння з шаблоном є анонімною функцією, що визначена як блок, що складається з послідовності випадків, заточений, як завжди, в фігурні дужки, але без ключового слова match перед блоком. Давайте перепишемо нашу функцію з застосуванням цієї нотації:

1
2

def wordsWithoutOutliers(wordFrequencies: Seq[(String, Int)]): Seq[String] =
  wordFrequencies.filter { case (_, f) => f > 3 && f < 25 } map { case (w, _) => w }

В цьому прикладі ми використовували тільки один випадок в кожній з наших анонімних функцій, оскільки ми знаємо, що цей випадок завжди співпадатиме – ми просто декопонували структуру даних, чий тип вже відомий під час компіляції, так що тут не може відбутись нічого поганого. Це дуже загальний спосіб використання порівняння шаблону з анонімними функціями.

Якщо ви будете намагатись присвоїти ці анонімні функції до значень, ви побачите, що вони матимуть очікуваний тип:

1
2

val predicate: ((String, Int)) => Boolean = { case (_, f) => f > 3 && f < 25 }
val transformFn: ((String, Int)) => String = { case (w, _) => w }

Будь ласка, зауважте, що вам треба вказати тип значення, компілятор Scala не може вивести його з анонімних функцій порівняння з шаблоном.

Звичайно, ніщо не заважає вам визначати більш складні послідовності випадків. Однак, якщо ви визначаєте анонімну функцію таким чином, та бажаєте передати ії в якусь іншу функцію, як в нашому прикладі,ви маєте переконатись, що для всіх можливих вводів співпадає з одним з ваших випадків, так, щоб ця ваша анонімна функція завжди повертала значення. Інакше ви ризикуєте отримати MatchError під час виконання.

Часткові функції

Іноді, однак, функція, що визначена тільки для специфічних значень вводу - це саме те, що вам потрібне. Фактично, таа функція може допомогти нам подолати іншу проблему, що все ще не вирішена, з нашою поточною реалізацією функціїwordsWithoutOutliers: ми спершу фільтруємо надану послідовність, та потім відображуємо елементи, що залишились. Якщо ми можемо утрусити це до рішення, що ітерує по послідовності тільки один раз, це не тільки зменшить цикли CPU, але також зробить код меньшим, та, нарешті, більш зрозумілим.

Якщо ви передивлялись Scala API для колекцій, ви могли помітити метод з назвоюcollect, що, для Seq[A]має наступну сигнатуру, :

1

def collect[B](pf: PartialFunction[A, B])

Цей метод повертає нову послідовність, застосовуючи надану часткову функццію до всіх елементів – часткова функція обоє, фільтрує та відображує послідовність.

Так що таке часткова функція? Коротко, це унарна функція, що, як відомо, визначена тільки для певних вхідних значень, та дозволяє клієнтам перевіряти, чи вона визначена для специфічного вхідного значення.

З цього боку, трейт PartialFunction провадить метод isDefinedAt. Фактично, типPartialFunction[-A, +B] поширює тип(A) => B (що також може бути записано як Function1[A, B]), та анонімна функція порівняння шаблону є завжди типуPartialFunction.

Через цю ієрархію наслідування, передача анонімної функції порівняння з шаблоном до метода, що очікуєFunction1, як  map або filter, є досить гарним, доки ця функція визначена для всіх вхідних значень, тобто завжди існує співпадаючий випадок.

Методcollect, однак, особливо очікує PartialFunction[A, B], що може бути визначена для всіх вхідних значень, та знає, як саме мати справу з цім випадком. Для кожного елементу в послідовності вона, спершу, перевіряє, чи часткова функція визначена для нього, викликаючи isDefinedAt на частково визначеній функції. Якщо це повертає false, елемент ігнорується. В іншому випадку, результат застосування часткової функції до елементу додається до результуючої послідовності.

Давайте спочатку визначимо часткову функцію, що ми бажаємо використати для рефакторингу нашої функції  wordsWithoutOutliers, щоб задіятиcollect:

1
2
3

val pf: PartialFunction[(String, Int), String] = {
  case (word, freq) if freq > 3 && freq < 25 => word
}

Ми додали твердження захисника до нашого випадку, так що ця функція не буде визначена до для пар слово/частота, чия частота не в потрібному диапазоні.

Замість використання синтаксису для анонімних фунцій порівняння шаблонів, ми можемо визначити цю часткову функцію, явно розширивши трейтPartialFunction:

1
2
3
4
5
6
7
8
9

val pf = new PartialFunction[(String, Int), String] {
  def apply(wordFrequency: (String, Int)) = wordFrequency match {
    case (word, freq) if freq > 3 && freq < 25 => word
  }
  def isDefinedAt(wordFrequency: (String, Int)) = wordFrequency match {
    case (word, freq) if freq > 3 && freq < 25 => true
    case _ => false
  }
}

Однак, зазвичай, ви побажаєте використовувати значно більш стислий синтаксис анонімних функцій.

Тепер, якщо ми передали нашу часткову функцію до метода map, це буде досить гарно компілюватись, але призведе доMatchError під час використання, оскільки наша часткова функція не визначена для всіх можливих вхідних значень, дякуючи до доданих тверджень захисників:

1

  wordFrequencies.map(pf) // will throw a MatchError

Однак ми можемо передати цю часткову функцію до метода collect, та він буде фільтрувати та відображувати послідовність, як очікується:

1

  wordFrequencies.collect(pf) // List("habitual", "homely", "society")

Результат цього такий же самий , як той, що дає наша поточна реалізація wordsWithoutOutliers, коли ми передаємо нашу умовну послідовність  wordFrequenciesдо неї. Таким чином, давайте перепишемо цю функцію:

1
2

def wordsWithoutOutliers(wordFrequencies: Seq[(String, Int)]): Seq[String] =
  wordFrequencies.collect { case (word, freq) if freq > 3 && freq < 25 => word }

Часткові функції мають деякі інші, дуже важливі функції. Наприклад, вони провадять умови для сціплення, дозволяючи милу функціональну альтернативу ланцюгам шалонів відповідальності, відомим з об'єкт-орієнтовного програмування. Це, однак, буде приводом для наступного посту в серії, де я збираюсь розглянути питання функціональної здатності до композиції.

Часткова функціональність є також накутним елементом багатьох бібліотек Scala та API. Наприклад, спосіб, яким актори Akka обробляють надіслані ним повідомлення, визначені в термінах часткових функцій. Таким чином, це досить важливо знати та розуміти цю концепцію.

Підсумок

І цій частині ми дослідили альтернативний шлях визначення анонімних функцій,  зокрема для послідовності випадків, що відкриває деякі милі можливості деструкції, в дещо компактному вигляді. Більше того, ми занурились в тему часткових функцій, демонструючи їх корисність в аспекті простого випадку.

В наступній главі я маю намір копати глибше в вездесущий тип Option, пояснюючи причини його існування, та його використання найкращим чином.

Будь ласка, дайте мені знати, якщо ви маєте жодні запитання або дещо. Чи є деякі теми, що ви бажаєте побачити в наступних статтях?

На протязі останніх тижнів ми просувались далі, та розлянули більшість підгрунтя, що відноситься до досить складних матерій, зокрема порівняння з шаблонами та екстракторів. Час вповільнитись, та поглянути на більш фундаментальні ідеосинкразичні речі Scala: тип Option.

Якщо ви брали курс Scala на Coursera, ви вже отримали коротке введення в цей тип, та бачили його в дії в MapAPI. В цій серії ми також використовували його, коли реалізували свої власні екстрактори. 

Але все ще залишилось багато, що треба прояснити про нього. Ви, можливо, дивувались, що це все за галас кругом, що такого значно кращого щодо опцій, ніж інших шляхів представлення відсутності значення. Ви також, можливо, не в курсі, як насправді робити з типом Option в вашому власному коді. Ціль цієї частини серії позбутися всіх ціх знаків запитань, та навчитись всьому, що насправді треба знати щодоOption,  в якості завзятого новачка Scala.

Базова ідея

Якщо ви взагалі робили з Java в минулому, дуже вірогідно, що ви мали в деякий момент NullPointerException (інші мови будуть викликати подібні помилки в такому ж випадку). Можливо це трапляється, оскільки деякий метод повертає null, коли ви не очікували його, і, таким чином, не розглядали таку можливість в клієнтському коді. Значення null часто невірно використовується для представлення відсутнього опціонального значення.

Деякі мови трактують значення null в осообливий спосіб, або дозволяють вам безпечно робити зі значеннями, що можуть бути null. Наприклад, Groovy має null-безпечний оператор для доступу до властивостей, так що foo?.bar?.baz не буде викликати виключення, якщо або foo, або його властивість bar є null, замість цього напряму повертаючи null. Однак ви схибите, якщо ви забудете використати цей оператор, та ніщо вас не змушує до цього.

Clojure загалом трактує своє значення nil як пусту річ, тобто як пустий список, якщо доступ іде як до списка, або як пусту мапу, якщо доступ іде як до мапи. Це означає, що значення nil підіймається вгору по ієрархії викликів. Дуже часто все гаразд, але іноді це призводить до виключення значно вище в ієрархії викликів, де деякий шматок кода не є nil-дружнім в кінці кінців.

Scala намагається вирішити проблему позбавлення від значень null, разом провадячи свій власний тип для представлення опціональних значень, тобто значень, що можуть бути присутніми, або ні: трейт Option[A].

Option[A] є контейнером для опціонального значення типу A. Якщо значення типу  A присутнє, Option[A] є примірником Some[A], що містить присутнє значення типу  A. Якщо значення відсутнє, Option[A] є об'єктом None.

Затверджуючи, що значення може бути, або не бути присутнім, на рівні типу, ви, та всі інши розробники, що роблять з вашим кодом, змушені компілятором мати справу з ціма можливостями. Немає способу, коли ви випадково будете покладатись на присутність значення, що насправді опціональне.

Option є обов'язковим! Не використовуйте null для позначення, що опціональне значення відсутнє.

Створення опції

Звичайно, ви можете просто створити Option[A] для існуючого значення, напряму уособивши кейс клас Some:

1

val greeting: Option[String] = Some("Hello world")

Або, якщо ви знаєте, що значення відсутнє, ви просто присвоюєте або повертаєте об'єкт None:

1

val greeting: Option[String] = None

Однак, час від часу вам треба взаємодіяти з бібліотеками Java, або кодом на других мовах JVM, що щасливо використовують null для позначення відсутніх значень. З цієї причини об'єкт-компанйон Option провадить метод-фабрику, що створює None, якщо параметр є null, інакше параметр огортається в Some:

1
2

val absentGreeting: Option[String] = Option(null) // absentGreeting буде None
val presentGreeting: Option[String] = Option("Hello!") // presentGreeting буде Some("Hello!")

Робота з опціональними значеннями

Це все мило, але як, насправді, робити з опціональними значеннями? Прийшов час для прикладу. Давайте зробимо щось нудне, так, щоб зконцентруватись на важливих речах.

Уявімо, що ви робите на одному з тих жахливих стартапів , і однією з перших речей, щ вам треба, є реалізація репозитарію користувачів. Нам треба бути в змозі знайти користувача за його унікальним id. Іноді запити приходять з деякими фіктивними id. Це закликає до типу повернення Option[User] для нашого метода пошуку. Умовна реалізація нашого репозитарію користувачів може виглядати так:

1
2
3
4
5
6
7
8
9
10
11
12
13

case class User(
  id: Int,
  firstName: String,
  lastName: String,
  age: Int,
  gender: Option[String])

object UserRepository {
  private val users = Map(1 -> User(1, "John", "Doe", 32, Some("male")),
                          2 -> User(2, "Johanna", "Doe", 30, None))
  def findById(id: Int): Option[User] = users.get(id)
  def findAll = users.values
}

Тепер, якщо ви отримали примірник Option[User] від UserRepository, та потребуєте зробити щось з ним, як це зробити?

Одним шляхом може бути перевірка, чи значення присутнє силами метода isDefinedвашої опції, та, якщо це так, отримати значення через метод get:

1
2
3
4

val user1 = UserRepository.findById(1)
if (user1.isDefined) {
  println(user1.get.firstName)
} // will print "John"

Це дуже подібно то того, як робить тип Optional бібліотеки Guava в Java. Якщо ви вважаєте, що це довге, та очікуєте дещо більш елегантне від Scala, ви на вірному шляху. Більш важливо, якщо ви використовуєте get, ви можете забути про перевірку isDefined перед цім, що призведе до виключення під час виконання, так що ви не отримаєте значно більше, ніж від використання null.

Ви повинні триматись подалі від цього шляху доступу до опцій, тільки як це можливо!

Провадження значення по замовчанню

Дуже часто ви бажаєте робити з вдкатом, або значенням по замовчанню, в випадку опціонального значення, що відсутнє. Це випадок використання є дуже гарно виражений методомgetOrElse, визначений для Option:

1
2

val user = User(2, "Johanna", "Doe", 30, None)
println("Gender: " + user.gender.getOrElse("not specified")) // will print "not specified"

Будь ласка зауважте, що значення по замовчанню, яке ви можете вказати як параметр до методу getOrElse, є параметром за ім'ям, що означає, що він обчислюється тільки якщо опція, на якій ви викликаєте getOrElse насправді None. Таким чином, немає потреби турбуватись, якщо створення значення по замовчанню є коштовним з однієї або іншої причини – це буде траплятись, тільки якщо значення по замовчанню буде насправді потрібним.

Порівняння з шаблоном

Some є кейс класом, так що чудово можливо використовувати його в шаблоні, буде це в звичайному виразі порівняння з шаблоном, або якомусь іншому дозволеному місці. Давайте перепишемо приклад вище, з використанням порівняння з шаблоном:

1
2
3
4
5

val user = User(2, "Johanna", "Doe", 30, None)
user.gender match {
  case Some(gender) => println("Gender: " + gender)
  case None => println("Gender: not specified")
}

Або, якщо ви бажаєте виключити дублікат твердження println, та використати факт, що ми робитмо з виразом порявняння з шаблоном:

1
2
3
4
5
6

val user = User(2, "Johanna", "Doe", 30, None)
val gender = user.gender match {
  case Some(gender) => gender
  case None => "not specified"
}
println("Gender: " + gender)

Можливо ви помітили, що порівняння з шаблоном примірника Optionдосить балакуче, через що зазвичай не є ідиоматичним обробляти опції в цей спосіб. Таким чином, навіть якщо ви всі захоплені щодо порівняння шаблонів, спробуйте використовувати альтернативи при роботі з опціями.

Є один досить елегантний шлях використання шаблонів з опціями, що ви навчитесь коли дійдете до розділу нижче про осяжності.

Опції можна розглядати як колекції

Доки ви не бачили багато елегантних ідеоматичних шляхів роботи з опціями. Тепер ми займемось цім.

Я завжди казав, що Option[A] є контейнером для значення типу A. Більш точно, ви можете думати про це, як про різновид колекції – деяка особлива сніжинка колекції, що містить або нуль елементів, або точно один елемент типуA. Це дуже потужна ідея!

Навіть, думаючи на рівні типу, якщо Option не є типом колекції в Scala, опції ідуть з усіма благами, що ви цінуєте в колекціях Scala, як List, Set,таке інше – та якщо вам дійно це треба, ви навіт можете трансформувати опції, наприклад, в List.

Так що це дозволяє нам робити?

Виконання побічних ефектів за наявності значення

Якщо ви бажаєте виконати деякий побічний ефект за наявності опціонального значення, метод foreach, відомий з колекцій Scala стане вам у пригоді:

1

UserRepository.findById(2).foreach(user => println(user.firstName)) // prints "Johanna"

Функція, передана до foreach, буде викликана один раз, якщо Option є Some, або жодного разу, якщо це None.

Відображення (мапи) опцій

Дійсно гарна річ щодо опцій в якості колекцій в тому, що ви можете робити з ними в дуже функціональний спосіб, та цей спосіб співпадає з тим, як виробите зі списками, наборами, etc.

Так само, як ви можете відобразити List[A] на List[B], ви можете відобразити Option[A]на Option[B]. Це означає, що якщо ваш примірник Option[A] є визначеним, тобто якщо це Some[A], результат є Some[B], інакше це None.

Якщо ви порівняєте Option з List, None еквівалентно пустому списку : коли ви відображуєте List[A], ви отримуєте пустий List[B], та коли ви відображуєте Option[A] що є None, ви отримуєте Option[B] що є None.

Давайте отримаємо рік опціонального користувача:

1

val age = UserRepository.findById(1).map(_.age) // age є Some(32)

flatMap та опції

Давайте зробимо те ж саме зі статтю:

1

val gender = UserRepository.findById(1).map(_.gender) // gender є Option[Option[String]]

Тип отриманого результату gender є Option[Option[String]]Чому це?

Подумайте про це таким чином: ви маєте контейнер Option для User, та всередині цього контейнера ви відображуєте примірник User на Option[String], оскікльки це тип даих для властивості gender класу User.

Ці вкладені опції є надокучливими? Ось чому, так само як всі колекції, Option також провадить метод flatMap. Точно як ви можете flatMap List[List[A]] до List[B], ви можете зробити те саме для Option[Option[A]]:

1
2
3

val gender1 = UserRepository.findById(1).flatMap(_.gender) // gender є Some("male")
val gender2 = UserRepository.findById(2).flatMap(_.gender) // gender є None
val gender3 = UserRepository.findById(3).flatMap(_.gender) // gender є None

Тип результата тепер Option[String]. Якщо користувач визначений, та його стать також визначена, ми отримуємо згладжений Some. Якщо або користувач, або стать не визначені, ми отримуємо None.

Щоб зрозуміти, як це робить, давайте подивимось, що відбувається при пласкому відображенні списка списків рядків, завжди маючи на думці, що Option є також колекцією, так само як List:

1
2
3
4
5
6

val names: List[List[String]] =
  List(List("John", "Johanna", "Daniel"), List(), List("Doe", "Westheide"))
names.map(_.map(_.toUpperCase))
// результат List(List("JOHN", "JOHANNA", "DANIEL"), List(), List("DOE", "WESTHEIDE"))
names.flatMap(_.map(_.toUpperCase))
// результат List("JOHN", "JOHANNA", "DANIEL", "DOE", "WESTHEIDE")

Якщо ми використовуємо flatMap, ми відображуємо елементи внутнішніх списків, та конвертуємо все в один плаский список рядків. Зрозуміло, нічого не залишиться від порожніх внутрішніх списків.

Щоб повернутись до типу Option, уявіть, що трапиться, якщо ви відобразите список опцій рядків:

1
2
3

val names: List[Option[String]] = List(Some("Johanna"), None, Some("Daniel"))
names.map(_.map(_.toUpperCase)) // List(Some("JOHANNA"), None, Some("DANIEL"))
names.flatMap(xs => xs.map(_.toUpperCase)) // List("JOHANNA", "DANIEL")

Якщо ви тільки відобразите список обцій, результат зостанеться  List[Option[String]]. З використанням  flatMap, всі елементи внутрішніх колекцій покладаються в плаский список: оидн елемент з кожного Some[String]в оригінальному списку розгорнуті, та покладені в результуючий список, тоді як любе значення None в оригінальному списку не містить жодного елементу, що має бути розгорнутий. Таким чином, значення None ефективно відфільтровуються.

З таким знанням, давайте подивимось знову, що робить flatMap на типі Option.

Фільтрація опцій

Ви можете фільтрувати опції, точно як ви фільтруєте список. Якщо примірник Option[A] визначений, тобто якщо це Some[A], та предикат, переданий до filter повертає true для огорнутого значення типу A, повертається примірник Some. Якщо примірник Option вже None, або предикат повертаєfalse для значення в  Some, результат None:

1
2
3

UserRepository.findById(1).filter(_.age > 30) // Some(user), бо age > 30
UserRepository.findById(2).filter(_.age > 30) // None, оскільки age є <= 30
UserRepository.findById(3).filter(_.age > 30) // None, бо user вже None

For осягнення

Тепер, коли ми знаємо, що Option може трактуватись як колекція, та провадить  map, flatMap, filter та інші методи, що ви знаєте з колекцій, ви, можливо, вже підозрюєте, що опції можуть бути використані в for осягненнях. Часто це найбільш читабельний шлях роботи з опціями, особилво якщо ви маєте зціпити багато map, flatMap та filter викликів. Якщо це тільки поодинокий map, це часто може бути переважним, бо це тільки трохи менш балакуче.

Якщо ви бажаєте отримати стать для окремого користувача, ми можемо застосувати наступну осяжність:

1
2
3
4

for {
  user <- UserRepository.findById(1)
  gender <- user.gender
} yield gender // результат є Some("male")

Як ви, можливо, знаєте з роботи зі списками, це еквівалентно до якладоних викликів flatMap. Якщо UserRepository вже повертає None, або Gender є None, результат осяжності є None. Для користувача в цьому прикладі визначена стать, так що вона буде повернута в Some.

Якщо ми бажаємо отримати статі для всіх користувачів, для яких ми її вказали, ми ітеруємо по всіх користувачах, та для кожного з них отримуємо стать, якщо вона визначена:

1
2
3
4

for {
  user <- UserRepository.findAll
  gender <- user.gender
} yield gender

Оскільки ми ефективно сплющили відображення, результуючий тип є List[String], та результуючий список є List("male"), оскільки gender визначений тільки для першого користувача.

Використання в лівій частині генератора

Можливо, ви пам'ятаєте з третьої частиницієї серій, що ліва частина генератора в осяжності є шаблоном. Це означає, що ви можете мати опції з шаблонами в ваших осяжностях.

Ми можемо переписати попередній приклад наступним чином:

1
2
3

for {
  User(_, _, _, _, Some(gender)) <- UserRepository.findAll
} yield gender

Використання шаблону Some в лівій стороні генератора має ефект видалення всіх елементів з результата колекції, для яких відповідне значення є None.

Сціплення опцій

Опції також можуть бути зціплені, що є трохи подібним до зціплення часткових функцій. Щоб зробити це, ви викликаєте orElse на примірнику Option, та передати інший примірник Option я параметр за ім'ям. Якщо останній є None, orElse повертає опцію, що передана йому, інакше він повертає той, на якому він викликаний.

Гарний приклад застосування для цього є пошук ресурсів, коли ви маєте декілька локацій, де його можна знайти, та порядок переваг. В нашому прикладі ми схильні шукати ресурс в каталозі конфігурації, так що ми викликаємо orElse на ньому, передаючи альтернативну опцію:

1
2
3
4

case class Resource(content: String)
val resourceFromConfigDir: Option[Resource] = None
val resourceFromClasspath: Option[Resource] = Some(Resource("I was found on the classpath"))
val resource = resourceFromConfigDir orElse resourceFromClasspath

Це загалом гарно підходить, якщо ви бажаєте зціпити більше ніж дві опції – якщо ви просто бажаєте запровадити значення по замовчанню, в випадку відсутності наданої опції, метод getOrElse може бути кращою ідеєю.

Підсумок

В цій главі я намагався надати все, що вам треба знати про тип Option, щоб використовувати його з користю, щоб розуміти код інших розробників Scala, та писати більш читаємий, функціональний код. Найбільш важливий висновок, що можна отримати з цього посту, полягає в тому, що є дуже проста базова ідея, загальна для списків, наборів, мап, опцій, та, як ви побачите в майбутніх постах, для інших типів даних, та існує одноманітний шлях використання ціх типів, що разом, елегантний та потужний.

В наступній частині цієї серії я збираюсь мати справу з ідиоматичною, функціональною обробкою помилок в Scala.

Коли ми тільки граємось з новою мовою, ви можете просто пройти повз факт, що дещо може пійти не так. Але як тільки ви захочете створити дещо серьйозне, ви не зможете більше втекти від обробки помилок та виключень у вашому коді. Важливість того, наскільки гарно мова підтримує вас для роботи над помилками часто недооцінюють, з тієї чи іншої причини.

Як з'ясовується, Scala досить гарно позиційована, коли річ доходить до обробки помилок. В цій главі я збираюсь презентувати підхід Scala до обробки помилок, базуючись на типі  Try, та обгрунтування цього. Я використовую можливості, введені в Scala 2.10, та портовані назад в Scala 2.9.3, так що переконайтесь, що ваша версія Scala в SBT є 2.9.3 або пізніша.

Підняння та перехоплення виключень

Перед переходом прямо до ідеоматичного підходу Scala до обробки помилок, давайте спершу подивимось на підхід, що більше скидається на те, що використовується для роботи з помилковими умовами, якщо ви прийшли з мов, як Java або Ruby. Як і ці мови, Scala дозволяє вам підіймати виключення:

1
2
3
4
5
6
7

case class Customer(age: Int)
class Cigarettes
case class UnderAgeException(message: String) extends Exception(message)
def buyCigarettes(customer: Customer): Cigarettes =
  if (customer.age < 16)
    throw UnderAgeException(s"Customer must be older than 16 but was ${customer.age}")
  else new Cigarettes

Підняті виключення можуть бути перехоплені, та оброблені дуже подібно до Java, хоча і з використанням часткової функції для визначення виключень, з якими ми бажаємо мати справи. Також, в Scala try/catch є виразом, так що наступний код повертає повідомлення з виключення:

1
2
3
4
5
6
7

val youngCustomer = Customer(15)
try {
  buyCigarettes(youngCustomer)
  "Yo, here are your cancer sticks! Happy smokin'!"
} catch {
    case UnderAgeException(msg) => msg
}

Обробка помилок, функціональний шлях

Тепер, маючи цей різновид коду обробки виключень по всьому вашому коду, може дуже швидко стати бридким, та не іде гарно в ногу з функціональним програмуванням. Це також досить погане рішення для застосувань з масовою конкурентністю. Наприклад, якщо вам треба мати справу з виключенням, викликаним в Actor, що виконується в іншому потоці, ви, очевидно, не можете зробити це, перехоплюючи виключення – ви будете бажати можливість отримувати повідомлення, що вказує на умови помилки.

Таким чином, в Scala зазвичай більш бажано вказати на виникнення помилки, повертаючи відповідне значення від вашої функції.

Не турбуйтесь, ми не збираємось повертатись до обробки помилок в стилі C, використовуючи коди помилок, що ми повинні перевіряти за домовленістю. Скоріше в  Scala ми використовуємо специфічні типи, що представляють обчислення, які можуть призвести до виключень.

В цій статті ми познайомимось з типом Try, що був введений в Scala 2.10, та пізніше портований назад до Scala 2.9.3. Є також інший тип, Either, який, навіть після появи Try, все ще може бути корисним, хоча і є більш загальним.

Семантика Try

Семантику Try краще пояснити в порівнянні з типом Option, що був темою попередньої частини цієї серії.

Коли Option[A] є контейнером для типу A, що може бути присутнім, або ні, Try[A]представляє обчислення, що може результувати в значенні типу A в випадку успіху, або в деякому Throwable, якщо дещо пішло не так. Примірники такого контейнерного типу можуть бути просто передані далі між конкурентно обчислюваними частинами вашого застосування.

Є два різні типи Try: якщо екземпляр Try[A]представляє успішне обчислення, він є примірником Success[A], просто огортаючий значення типи A. Якщо, з іншого боку, він представляє обчислення, де виникла помилка, це примірник Failure[A], огортаючи Throwable, тобто виключення, або іншу помилку.

Якщо ми знаємо, що обчислення може завершитись з помилкою, ми просто можемо використати Try[A] як тип повернення для цієї функції. Це робить можливість явною, та змушує клієнтів наших функцій вирішувати можливість помилки, так чи інакше.

Наприклад, давайте уявимо, що ми бажаємо написати простий завантажувач веб сторінок. Користувач буде в змозі ввести URL веб сторінки, що треба отримати. одна частина вашого застосування буде функцією, що розбиратиме введений  URL, та створювати  java.net.URL з нього:

1
2
3

import scala.util.Try
import java.net.URL
def parseURL(url: String): Try[URL] = Try(new URL(url))

Як ви можете бачити, вона повертає значення типу Try[URL]. Якщо наданий url є синтаксично коректним, це буде Success[URL]. Якщо, однак,  конструктор URL викликає MalformedURLException, це буде Failure[URL].

Щоб досягти цього ми викорстовуємо метод-фабрику apply на об'єкті-компанйоні Try. Цей метод очікує параметр за-ім'ям типу A(тут URL). Для нашого прикладу це означає, що new URL(url) виконується зсередини метода apply об'єкта Try . В цьому методі перехоплюються нефатальні виключення, повертаючи Failure, що містить відповідне виключення.

Таким чином, parseURL("http://danielwestheide.com") буде давати Success[URL],  що містить створений URL, тоді як parseURL("garbage") дасть Failure[URL]з  MalformedURLException.

Робота зі значеннями Try

Робота з примірниками Try насправді дуже подібне до роботи зі значеннями Option, так що ви не побачите тут багато сюрпризів.

Ви можете перевірити, чи Try успішне, викликаючи isSuccess на ньому, та потім умовно отримати огорнуте значення, викликаючи get на ньому. Але вірте мені, не багато ситуацій, коли вам знадобиться робити це.

Також є можливим використати getOrElse для передачі значення по замовчанню, якщо Try є Failure:

1

val url = parseURL(Console.readLine("URL: ")) getOrElse new URL("http://duckduckgo.com")

Якщо наданий URL невірно сконфігурований, ми використовуємо URL DuckDuckGo як відкат.

Ланцюжки операцій

Одна з найбільш важливих характеристик типу Try в тому, що, як і Option, він підтримує всі високорівневі методи, що ви знаєте з інших типів колекцій. Як ви побачите в наступних прикладах, це дозволяє вам сціплювати операції зі значеннями Try, та перехоплювати можливі виключення, та все це в дуже прозорій манері. 

Мепінг та плаский мепінг

Мепінг (відображення) Try[A], що  є Success[A], до Try[B], повертає Success[B]. З іншого боку, якщо це Failure[A], результат Try[B] буде Failure[B], що міститиме те ж виключення, що і Failure[A]:

1
2
3
4

parseURL("http://danielwestheide.com").map(_.getProtocol)
// повертає Success("http")
parseURL("garbage").map(_.getProtocol)
// повертає Failure(java.net.MalformedURLException: no protocol: garbage)

Якщо ви зціпите декілька операцій map, це призведе до вкладеної структури Try, яка, звичайно, не є тим, що вам потрібно. Розгляньте цей метод, що повертає вхідний потік для наданого URL:

1
2
3
4

import java.io.InputStream
def inputStreamForURL(url: String): Try[Try[Try[InputStream]]] = parseURL(url).map { u =>
  Try(u.openConnection()).map(conn => Try(conn.getInputStream))
}

Оскільки анонімна функції, передані до двох викликів map кожний повертає Try, загальний тип результата Try[Try[Try[InputStream]]].

Тут вам допоможе факт присутності метода flatMap з Try. Метод flatMap на  Try[A] очікує функцію, що отримує A, та повертає Try[B]. Якщо наш примірник  Try[A] вже Failure[A], цей збій буде повернутий як Failure[B], просто передаючи огорнуте виключення далі по ланцюжку. Якщо наш Try[A] є Success[A], flatMap розпаковує значення A в ньому, та відображує його на Try[B], передаючи це значення до функції мепінгу.

Це означає, що ви загалом можете створити конвеєр операцій, що потребує значення, передані через примірники Success, зціплюючи довільне число викликів методу  flatMap. Любе виключення, що трапляється на шляху, огортається в Failure, що значить, що кінцевий результат ланцюжка операцій також буде Failure.

Давайте перепишемо метод inputStreamForURL з попереднього прикладу, на цей час з  flatMap:

1
2
3

def inputStreamForURL(url: String): Try[InputStream] = parseURL(url).flatMap { u =>
  Try(u.openConnection()).flatMap(conn => Try(conn.getInputStream))
}

Тепер ми отримали Try[InputStream], що може бути Failure, що огортає виключення з любого зі стадій, в якому він був викликаний, або Success, що напряму огортає  InputStream, фінальний результат нашого ланцюжка операцій.

Фільтри та foreach

Звичайно, ви також можете фільтрувати Try або викликати foreach на ньому. Обоє роблять саме так, як ви очікуєте після ознайомлення з Option.

Метод filter повертає Failure, якщо Try, на якоми ви його викликаєте, вже  Failure, або якщо предикот, на якому ви його викликаєте, повертає false (в якому випадку огорнуте виключення є NoSuchElementException). Якщо Try, на якому ви викликаєте, є Success, та предикат повертає true, цей примірник Succcess повертається незмінним:

1
2
3

def parseHttpURL(url: String) = parseURL(url).filter(_.getProtocol == "http")
parseHttpURL("http://apache.openmirror.de") // повертає Success[URL]
parseHttpURL("ftp://mirror.netcologne.de/apache.org") // повертає Failure[URL]

Функція, передана до foreach,  виконується тільки якщо Try є Success, що дозволяє  вам виконувати побічні ефекти. Функція, що передана до foreach, в цьому випадку виконується рівно один раз, будучи переданою як значення, огорнуте в Success:

1

parseHttpURL("http://danielwestheide.com").foreach(println)

For осяжності

Підтримка flatMap, map та filter означає, що ви можете також використовувати for осяжності, щоб зціпити операції примірників Try. Звичайно, це приводить до більш читабельного коду. Щоб продемонструвати це, давайте реалізуємо метод, що повертає вміст веб сторінки з даним URL, з використанням осяжностей.

1
2
3
4
5
6
7
8

import scala.io.Source
def getURLContent(url: String): Try[Iterator[String]] =
  for {
    url <- parseURL(url)
    connection <- Try(url.openConnection())
    is <- Try(connection.getInputStream)
    source = Source.fromInputStream(is)
  } yield source.getLines()

Є три місця, де речі можуть пійти не так, всі з них конвертовані використанням типу Try. Перше, вже реалізований метод  parseURL повертає Try[URL]. Тільки якщо це Success[URL], ми будемо намагатись відкрити з'єднання та створювати новий вхідний потік для нього. Якщо відкриття з'єднання та створення вхідного потоку буде успішним, ми продовжимо, нарешті отримуючи рядки веб сторінки. Оскільки ми ефективно зціпили декілька викликів flatMap в цій осяжності, тип результату буде пласким  Try[Iterator[String]].

Будь ласка, занотуйте, що це може бути спрощено з використанням Source#fromURL, та ще ми забули закрити наш вхідний потік в кінці. Обоє через моє рішення тримати приклад сфокусованим на предметі.

Порівняння з шаблоном

В деякій точці вашого коду ви забажаєте знати, чи примірник Try, що ви отримали як результат деякого обчислення, представляє успіх або ні, та виконати різні гілки коду в залежності від результату. Звичайно, це те місце, де ви задієте порівняння з шаблоном. Це просто можливо, оскільки обоє, Success та Failure є case класами.

Ми бажаємо відобразити запитану сторінку, якщо вона може бути отриманою, або надрукувати повідомлення, якщо ні:

1
2
3
4
5
6

import scala.util.Success
import scala.util.Failure
getURLContent("http://danielwestheide.com/foobar") match {
  case Success(lines) => lines.foreach(println)
  case Failure(ex) => println(s"Problem rendering URL content: ${ex.getMessage}")
}

Відновлення після збою

Якщо ви бажаєте встановити деякий різновид поведінки по замовчанню в випадку  Failure, вам не треба використовувати getOrElse. Альтернативою єrecover, який очікує часткову функцію, та повертає інший Try. Якщо recover викликаний до примірника Success, цей примірник повертається як є. Інакше, якщо часткова функція визначена для примірника Failure, її результат повертається як Success.

Давайте використаємо це, щоб надрукувати різні повідомлення, залежно від типу огорнутого виключення:

1
2
3
4
5
6
7

import java.net.MalformedURLException
import java.io.FileNotFoundException
val content = getURLContent("garbage") recover {
  case e: FileNotFoundException => Iterator("Requested page does not exist")
  case e: MalformedURLException => Iterator("Please make sure to enter a valid URL")
  case _ => Iterator("An unexpected error has occurred. We are so sorry!")
}

Тепер ми можемо безпечно get огорнуте значення на Try[Iterator[String]], що ми присвоїли до content, оскільки ми знаємо, що це має бути Success. Виклик content.get.foreach(println) буде продукувати друк на контролі Please make sure to enter a valid URL.

Висновок

Ідеоматична обробка помилок в Scala досить відрізняється від парадігми, відомої з таких мов, як Java або Ruby. Тип Tryдозволяє вам інкапсулювати обчислення, що можуть продукувати помилки, в контейнер, та зціпити операції обчислених значень в дуже елегантний спосіб. Ви можете застосовувати ваші відомості про колекції та значення  Option до того, як обробляти код, що може викликати помилки – все це в одноманітний спосіб.

Щоб підтримувати цю статтю помірної довжини я не розповідаю про всі методи, доступні до Try. Як Option, Try підтримує метод orElse. Методи transform та recoverWith також варті вашої уваги, та я закликаю подивитись на них.

В наступній частині ми маємо намір мат справу з Either, альтернативним типом для представлення обчислень, що можуть призвести до помилок, але з більшим полем зору застосування за межами обробки помилок.

1
2
3
4
5
6
7

import scala.io.Source
import java.net.URL
def getContent(url: URL): Either[String, Source] =
  if (url.getHost.contains("google"))
    Left("Requested URL is blocked for the good of the people!")
  else
    Right(Source.fromURL(url))

1
2
3
4

getContent(new URL("http://google.com")) match {
  case Left(msg) => println(msg)
  case Right(source) => source.getLines.foreach(println)
}

1
2
3
4
5
6

val content: Either[String, Iterator[String]] =
  getContent(new URL("http://danielwestheide.com")).right.map(_.getLines())
// content є Right, що містить рідяки, повернуті  getContent
val moreContent: Either[String, Iterator[String]] =
  getContent(new URL("http://google.com")).right.map(_.getLines)
// moreContent є Left, вже повернутий getContent

1
2
3
4
5
6

val content: Either[Iterator[String], Source] =
  getContent(new URL("http://danielwestheide.com")).left.map(Iterator(_))
// content є Right, що містить Source, вже повернутий getContent
val moreContent: Either[Iterator[String], Source] =
  getContent(new URL("http://google.com")).left.map(Iterator(_))
// moreContent є Left, що містить msg, що повернув getContent в Iterator

1
2
3
4
5

val part5 = new URL("http://t.co/UR1aalX4")
val part6 = new URL("http://t.co/6wlKwTmu")
val content = getContent(part5).right.map(a =>
  getContent(part6).right.map(b =>
    (a.getLines().size + b.getLines().size) / 2))

1
2
3

val content = getContent(part5).right.flatMap(a =>
  getContent(part6).right.map(b =>
    (a.getLines().size + b.getLines().size) / 2))

1
2
3
4
5

def averageLineCount(url1: URL, url2: URL): Either[String, Int] =
  for {
    source1 <- getContent(url1).right
    source2 <- getContent(url2).right
  } yield (source1.getLines().size + source2.getLines().size) / 2

1
2
3
4
5
6
7

def averageLineCountWontCompile(url1: URL, url2: URL): Either[String, Int] =
  for {
    source1 <- getContent(url1).right
    source2 <- getContent(url2).right
    lines1 = source1.getLines().size
    lines2 = source2.getLines().size
  } yield (lines1 + lines2) / 2

1
2
3
4
5
6
7
8

def averageLineCountDesugaredWontCompile(url1: URL, url2: URL): Either[String, Int] =
  getContent(url1).right.flatMap { source1 =>
    getContent(url2).right.map { source2 =>
      val lines1 = source1.getLines().size
      val lines2 = source2.getLines().size
      (lines1, lines2)
    }.map { case (x, y) => x + y / 2 }
  }

1
2
3
4
5
6
7

def averageLineCount(url1: URL, url2: URL): Either[String, Int] =
  for {
    source1 <- getContent(url1).right
    source2 <- getContent(url2).right
    lines1 <- Right(source1.getLines().size).right
    lines2 <- Right(source2.getLines().size).right
  } yield (lines1 + lines2) / 2

1
2
3
4

val content: Iterator[String] =
  getContent(new URL("http://danielwestheide.com")).fold(Iterator(_), _.getLines())
val moreContent: Iterator[String] =
  getContent(new URL("http://google.com")).fold(Iterator(_), _.getLines())

1
2
3

import scala.util.control.Exception.catching
def handling[Ex <: Throwable, T](exType: Class[Ex])(block: => T): Either[Ex, T] =
  catching(exType).either(block).asInstanceOf[Either[Ex, T]]

1
2
3

import java.net.MalformedURLException
def parseURL(url: String): Either[MalformedURLException, URL] =
  handling(classOf[MalformedURLException])(new URL(url))

1
2
3
4
5
6

case class Customer(age: Int)
class Cigarettes
case class UnderAgeFailure(age: Int, required: Int)
def buyCigarettes(customer: Customer): Either[UnderAgeFailure, Cigarettes] =
  if (customer.age < 16) Left(UnderAgeFailure(customer.age, 16))
  else Right(new Cigarettes)

1
2
3
4
5
6
7
8
9

type Citizen = String
case class BlackListedResource(url: URL, visitors: Set[Citizen])

val blacklist = List(
  BlackListedResource(new URL("https://google.com"), Set("John Doe", "Johanna Doe")),
  BlackListedResource(new URL("http://yahoo.com"), Set.empty),
  BlackListedResource(new URL("https://maps.google.com"), Set("John Doe")),
  BlackListedResource(new URL("http://plus.google.com"), Set.empty)
)

1
2
3
4

val checkedBlacklist: List[Either[URL, Set[Citizen]]] =
  blacklist.map(resource =>
    if (resource.visitors.isEmpty) Left(resource.url)
    else Right(resource.visitors))

1
2

val suspiciousResources = checkedBlacklist.flatMap(_.left.toOption)
val problemCitizens = checkedBlacklist.flatMap(_.right.toOption).flatten.toSet

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

import scala.util.Try
// Деякі псевдоними типів, тільки для отримання більш осмислених сигнатур методів:
type CoffeeBeans = String
type GroundCoffee = String
case class Water(temperature: Int)
type Milk = String
type FrothedMilk = String
type Espresso = String
type Cappuccino = String
// умовна реалізація окремих кроків:
def grind(beans: CoffeeBeans): GroundCoffee = s"ground coffee of $beans"
def heatWater(water: Water): Water = water.copy(temperature = 85)
def frothMilk(milk: Milk): FrothedMilk = s"frothed $milk"
def brew(coffee: GroundCoffee, heatedWater: Water): Espresso = "espresso"
def combine(espresso: Espresso, frothedMilk: FrothedMilk): Cappuccino = "cappuccino"
// деякі виключення для речей, що можуть пійти не так на окремих кроках
// (нам знадобляться деякі пизніше, використовуйте інші коли експирементуємо
// з кодом):
case class GrindingException(msg: String) extends Exception(msg)
case class FrothingException(msg: String) extends Exception(msg)
case class WaterBoilingException(msg: String) extends Exception(msg)
case class BrewingException(msg: String) extends Exception(msg)
// проходимо цей код послідовно:
def prepareCappuccino(): Try[Cappuccino] = for {
  ground <- Try(grind("arabica beans"))
  water <- Try(heatWater(Water(25)))
  espresso <- Try(brew(ground, water))
  foam <- Try(frothMilk("milk"))
} yield combine(espresso, foam)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

import scala.concurrent.future
import scala.concurrent.Future
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent.duration._
import scala.util.Random

def grind(beans: CoffeeBeans): Future[GroundCoffee] = Future {
  println("start grinding...")
  Thread.sleep(Random.nextInt(2000))
  if (beans == "baked beans") throw GrindingException("are you joking?")
  println("finished grinding...")
  s"ground coffee of $beans"
}

def heatWater(water: Water): Future[Water] = Future {
  println("heating the water now")
  Thread.sleep(Random.nextInt(2000))
  println("hot, it's hot!")
  water.copy(temperature = 85)
}

def frothMilk(milk: Milk): Future[FrothedMilk] = Future {
  println("milk frothing system engaged!")
  Thread.sleep(Random.nextInt(2000))
  println("shutting down milk frothing system")
  s"frothed $milk"
}

def brew(coffee: GroundCoffee, heatedWater: Water): Future[Espresso] = Future {
  println("happy brewing :)")
  Thread.sleep(Random.nextInt(2000))
  println("it's brewed!")
  "espresso"
}

1
2
3

object Future {
  def apply[T](body: => T)(implicit execctx: ExecutionContext): Future[T]
}

1
2
3

grind("arabica beans").onSuccess { case ground =>
  println("okay, got my ground coffee")
}

1
2
3
4
5

import scala.util.{Success, Failure}
grind("baked beans").onComplete {
  case Success(ground) => println(s"got my $ground")
  case Failure(ex) => println("This grinder needs a replacement, seriously!")
}

1
2
3
4

val temperatureOkay: Future[Boolean] = heatWater(Water(25)).map { water =>
  println("we're in the future!")
  (80 to 85).contains(water.temperature)
}